NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/9804

Text File | 1996-08-05 | 13.5 KB | 515 lines

Newsgroups: comp.lang.ada,comp.lang.apl,comp.lang.x86,comp.lang.asm370,comp.lang.awk,comp.lang.basic.misc,comp.lang.basic.visual.3rdparty,comp.lang.basic.visual.database,comp.lang.basic.visual.misc,comp.lang.beta,comp.lang.c,comp.lang.c++
Path: bcc.ac.uk!news
From: David Fulton <dfulton>
Subject: System Development Survey
Message-ID: <[e-mail]>
Date: Mon, 4 Mar 1996 16:06:00 GMT
X-Url: news:comp.lang.ada
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
X-Mailer: Mozilla 1.1N (X11; I; SunOS 4.1.3_U1 sun4c)
Organization: University College London

System Development Survey

Dear Reader,

This survey is part of a PhD research study looking at the links between the
organisational context in which a system is developed, the problem being
tackled and the system development strategy utilised. Currently, knowledge of
the type of pressures and problems faced by developers is fragmented across
case studies particular to individual disciplines (HCI, Safety-related etc). I
am looking for input from system development professionals from a range of
disciplines in order that parallels (and contrasting interpretations) across
different areas of system development can be drawn.

Those of you with form-compatible WWW browsers are cordially invited to
contribute to this research by accessing a survey web-page at:

http://boom.cs.ucl.ac.uk/staff/dfulton/survey.html

For those who are interested in the research but do not have form-compatible
web browsers, a text version follows which can be returned to:

[e-mail]

Many thanks!

David Fulton
--------------------------------------------------

Please fill in all sections in as much detail as possible. The form should take
around 10-15 minutes to complete.


Personal details are only recorded so that we can get back to you - if
required. Otherwise, individuals remain anonymous and your input is kept
confidential.

Your name:

Organisation:

Email Addr:

1: The Project

You are asked to complete this questionnaire in relation to a recent (or
current) project with which you are familiar.

1.1) What was the title of the project?


1.2) Please give a brief description of the project? (if possible):







1.3) What system characteristics did the product incorporate? (more than one of
the options can be ticked by marking them with an 'X'):

___     Interactive

___     Safety-Related *

___     Real-Time

___     Embedded *

___     Defence


* Safety-related projects being developments where safety (in whatever form) is
an important non-functional requirement. Embedded projects being software
systems that are used to run hardware


2: Focus of Analysis/Initial Statement of Objectives

2.1) Please mark the development paradigm used by the project:

___     In-house development- for another part of the company

___     Contract-based development- for an outside client

___     Generic/Shrink-Wrap development- for general use

2.2) Which of the following most closely describe the starting point for the
project?

___    The project started out without a clear view of the system
    to be developed, or of the underlying problem to be tackled

___    The project started out with an explicit problem to tackle
    but without a clear definition of the expected application

___    The project started with an explicit problem to ameliorate
    and a clear definition of the expected application

___    The project started with an explicit problem to solve and a
    clear definition of the expected application. In addition,
    the client has set the acceptance criteria for the project,
    and penalty provisions if criteria were not met



3: Development Pressures

3.1) Was the system to be developed designed to replace an existing manual or
automated organisational system?

___    Yes?

___    No?


3.2) Which of the following describes the development pressures (in generating
and using requirements) faced by the project?

NB: Only make a choice here if the system was to be used by a user/operator and
had an identifiable user population.

___    Users/Representatives had little or no experience with a
    system of this kind. As a result, they were unable to offer
    tangible requirements or ideas until a concrete
    representation (prototype) was available

___    Users/Representatives had some experience with similar
    systems in the past and they were able to put forward ideas
    and requirements for future systems



The next section looks at the skills of developers and the degree to which
their familiarity with the application being developed contributed to their
knowledge of a suitable definition.

3.3) Which of the following, in your opinion, describes the degree to which
developers (in general) were experienced in this type of development?

___    Developers had limited experience in developing a system of
    this kind and some experimentation was required to evaluate
    technical options

___    Developers had some experience of developing similar
    systems in the past and had a limited ability to predict
    changes or other types of uncertainty

___    Developers were experts in a particular problem domain
    and had a clearer understanding of technical options and
    possible solutions


4: The Organisational Context

In considering the organisational context, we are really looking at the context
within which the project is based, and are therefore looking at the structures
and processes (specific to the project) within the developer organisation, the
client organisation (if the two differ), and developer/client communication.

4.1: Structure of the project

4.1.1) Which of the following most closely describe the job roles within the
project?

___    Responsibilities and job roles were explicitly defined.
    No-one on the project could carry out tasks for which they
    did not have authorisation

___    While there were notional job roles and responsibilities,
    project personnel tended to carry out a range of tasks when
    they were required to do so



4.1.2) Which of the following most closely describes the manner in which
changes or requests for verification were addressed?

___    All requests for changes had to be routed via the project
    manager or to personnel at a higher level in the project
    structure.

___    Possible changes would generally be discussed by the
    appropriate parties before action was decided (on an
    informal basis).



4.2: Processes within the project

4.2.1) Which of the following describe the degree of stability in
project-related processes?

___    Processes were largely stable. Interaction between
    stakeholders in the project occured at pre-determined
    times.

___    Processes were subject to change. Interaction between
    stakeholders in the project was random - occured as and
    when needed.



5: System Development Strategy

5.1) In your opinion, which of the following points most closely summarise the
system development strategy that was taken?

___    The emphasis was on a constantly changing specification,
    adaptive code and minimal use of design documentation.

___    The emphasis was on the use of experimental methods,
    including evolutionary or iterative prototyping.

___    The emphasis was on producing a robust design and
    implementation, but allowing limited flexibility and
    ability to react to change.

___    The emphasis was on the production of error-free code
    and an accurate transformation of the specification into
    design material.



5.2) Which of the following most closely match the model of development used?

___    Stage-based models of development: A variation on the
    waterfall software life-cycle model is used

___    Iterative models of development: Spiral or iterative build
    models of development are utilised


5.3) Which of the following most closely match the emphasis of the development
strategy?

___    Emphasis on high-level design: Design activities are
    closely regulated and monitored

___    Emphasis on a mixture of high and low-level design:
    Although some procedural restrictions may be in place,
    low-level design tasks are largely unregulated

___    Emphasis on low-level design: There was little regulation
    of day to day practice


6: Outstanding issues

6.1) As far as you can recollect, what forms of changing requirements had a
particular impact on the project and what was the extent of that impact?

 Answers on the bi-polar scale refer to how confident you are with options at
each end of the scale. If you feel that there is a 'major impact' choose the
option on the far right. If you felt there was some impact, but you don't feel
you could define it using either of the opposing labels, then choose one of the
options in-between


6.1.1) Mutable Requirements: Changes brought about by changing organisational
goals and environmental turbulence eg. change because of organisational
restructuring mid-way through the project

Negligable impact    1    2    3    4    5     Major impact

6.1.2) Consequential Requirements: Changes brought about as a consequence of
particular design decisions, or through the testing of prototypes eg. change
when users discover new ways of working etc, change when technical staff
discover a new way of solving a technical problem

Negligable impact     1    2    3    4    5     Major impact

6.1.3) Migration Requirements: Changes when there are difficulties in moving
from the current state to the desired state eg, change when considerations have
to be made for the technical platforms the working version will have to work
on, data management etc

Negligable impact     1    2    3    4    5     Major impact

6.1.4) Emergent Requirements: Changes when participants slowly develop a better
understanding of what they really want eg, Users clarifying what they really
want and negating previous requirements

Negligable impact    1    2    3    4    5     Major impact

6.2) Was a method or methodology used in order to aid the analysis and design
of the system?

___     Yes?

___    No?


6.3) If the answer to the last question was 'Yes', which method(ology) was
used?

___    Information Engineering

___    SSADM

___    Yourdon (or SA/SD)

___    A Systems approach (SSM, ETHICS etc)

___    An Object-Oriented Method

___    Jackson Structured Design

or other (please specify)





6.4) if the answer to question 6.2 was 'yes'- Was the method used in its
entirety?

___    Yes?

___    No?



If not, what aspects of the method were not used, and why?











6.5) Which of the following tools or techniques were used on the project? (A
number of selections can be made)

___    Structure Charts

___    Data Flow Diagrams

___    Entity-Life Histories

___    Brainstorming

___    JAD Workshops

___    Prototyping Reviews

___    Entity-Relationship Models

___    Rich Pictures

___    Flow-Charts

___    Class diagrams

___    State Transition Diagrams

___    Storyboarding


or other (please specify)










6.6) Which tools or techniques do you feel are particularly important (given
the project you were working on), and why?








6.7) In your opinion, what are the tool or technique characteristics (for
analysis and design) that you feel are particularly important? (for the project
you were working on)

6.7.1) Tools/techniques that help us to experiment, attempt different
interpretations in order to improve understanding of the design problem or make
choices with design alternatives

Not Important    1    2    3    4    5    Very Important


6.7.2) Tools/techniques that help to illustrate the underlying models of the
system, illustrating system behaviour, structure etc.

Not Important    1    2    3    4    5    Very Important


6.7.3) Tools/techniques that give us a concrete idea of the way in which a
system can be realised and give a visible impression of what the system will
look like

Not Important    1    2    3    4    5    Very Important


6.7.4) Tools/techniques that help in communicating important analysis or design
information between the designers, or between designers and other participants

Not Important    1    2    3    4    5     Very Important


6.7.5) Tools/techniques that help us to explore analysis and design issues, to
explore issues of complexity and aid the understanding of complex
organisational and technological problems

Not Important    1    2    3    4    5     Very Important




7: Problems

7.1) In any given situation, there will be a number of constraints that can
hinder the strategy chosen for system development. How applicable were the
following situations to your project?


7.1.1) New requirements or changing requirements were coming in at too fast a
rate for us to cope effectively

Not Applicable         1    2    3    4    5    Very Applicable


7.1.2) It would have been nice if we could get together with the user
representatives on a more regular basis, as it was, we were just getting too
little feedback

Not Applicable        1    2    3    4    5    Very Applicable


7.1.3) We had a number of difficulties in fitting the approach we took with the
quality assurance procedures that we had to follow

Not Applicable         1    2    3    4    5     Very Applicable


7.1.4) Turnover of staff (with connections to the project) was a major problem
and distrupted the project.

Not Applicable         1    2    3    4    5     Very Applicable


7.1.5) Too much attention was paid to user interface issues and not enough to
the underlying functionality of the system

Not Applicable        1    2    3    4    5     Very Applicable


7.1.6) Getting agreement on changes was a time-consuming process, even when the
change seemed to be very minor.

Not Applicable         1    2    3    4    5     Very Applicable



8: General Comments

Are there any other aspects of development practice that you feel are
particularly important and haven't been covered within this survey? Are there
any other points that you would like to make?













9: On completion of this survey would you like a summary of results?

___    Yes?

___    No?



Many thanks for taking the time to fill in this form!

David Fulton
Department of Computer Science
University College London